Googleは最近、正当に築き上げてきた誇りを抱きつつ、次のような 発表をしました 。

Googleは、先日開催された2015 Open Network Summitで、5世代の社内ネットワーク テクノロジーの詳細を初めて公開しました。初の社内データセンターネットワークである10年前のFirehoseから最新世代のJupiterネットワークに至るまで、Googleは1つのデータセンターネットワークの能力を100倍以上に増強してきました。実際、現在のJupiterファブリックは二分割帯域幅で1ペタビット/秒を超えています。これだけの能力があれば、10万台のサーバがそれぞれ10Gb/秒で情報を交換でき、アメリカ国会図書館所蔵図書のスキャンしたコンテンツ全体を1/10秒未満の時間で読み込むことができるでしょう。

Googleのデータセンターネットワークは、目に見えるGoogleのほとんどの仕事を背後から支える基盤のようなものですが、この「二分割帯域幅」とはどんなもので、なぜそれが重要なのでしょうか。二分割帯域幅については、以前に Changing Architectures: New Datacenter Networks Will Set Your Code And Data Free（アーキテクチャを変える：新しいデータセンターネットワークがコードやデータを解放する） で話しました。手短に言うと、二分割帯域幅とはGoogleのサーバが相互に通信するために使うネットワークのことを指しています。

データセンターネットワークは、以前はユーザとの通信が中心でした。例えばWebページへの要求がブラウザから送られてきたとしましょう。その要求がサーバに到達すると、サーバは他の2、3のサーバとだけ通信して、あるいは他のサーバとは通信さえもせずに応答を生成しクライアントに返していました。このようなネットワークの型はNorth-South（北-南、垂直型）ネットワークと呼ばれています。この場合、要求の遂行に内部的な通信はほとんど必要ありません。

この通信の形態は、WebサイトやAPIの機能が時間と共に充実してきたことで一変しました。現在では、サイトの1ページを作るためでさえ 数千もの バックエンド要求が出されることもあります。驚きですよね。つまり、対ユーザが中心だった通信の型が、データセンター内の他のマシンに向けた通信へとシフトしたというわけです。このような型はEast-West（東-西、水平型）ネットワークと呼ばれています。

東西型主体の通信パターンへと移行したことで、データセンターネットワークには異なる トポロジー が必要となってきます。従来の ファットツリー 型ネットワーク設計では事足りなくなるため、何か新しいもので置き換えなければなりません。

Googleは、 The Datacenter as a Computer（単一コンピュータとしてのデータセンター） という同社のビジョンに先導される形で、リッチサービス対応のネットワーク設計に関して最前線を走ってきました。データセンターがコンピュータであれば、ネットワークは単一コンピュータの バックプレーン と同等と言えるでしょう。リモートのディスクやストレージにローカルのごとくアクセスするためにも、できる限り高速かつ信頼性の高いネットワークが必要となります。

Googleの挑戦は3つの計画を中心に展開されています。1つ目は Closトポロジー を使うこと、2つ目は SDN（Software Defined Networking） を使うこと、そして3つ目はGoogleらしいやり方で独自のカスタム装置を構築することです。

これまでのGoogleは、ネットワークの設計に関して公開を制限してきました。ただ今回は、 ONS（Open Networking Summit）2015の水曜日の基調講演 において、Googleのフェローでネットワーク技術責任者の Amin Vahdat が、その詳細について全てではありませんが非常に興味深い話をしてくれました。また、 Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network（台頭するJupiter：GoogleのデータセンターネットワークにおけるClosトポロジーと集中管理の10年 という参考になる研究論文もあります。

なぜGoogleはこの段階で詳細をリリースしたのでしょうか。考えられるのが、GoogleはAmazonと激しく競合しており、説得力のある差別化のポイントを探し出す必要があったということでしょう。Googleはそのような点の1つとして、自社のデータセンターネットワークに期待をかけています。

では、Googleの違いとは何でしょうか。概要は次の通りです。

• ムーアの法則の終焉は、プログラムの構築方法の変化を意味する。
• その回答を見つけたGoogleは優れたネットワークを構築し、適切なデータセンターのバランスを達成する方法を心得ている。
• Google検索と同じプラットフォームで動くGoogleのクラウドプラットフォームの革新性や性能は、利用者を成功させることができる。
• ぜひネットワークを試してほしい。

どうですか。万人の心をつかむメッセージではないものの、一部の人を取り込むことはできるのではないでしょうか。

講演において私が重要だと感じた点を以下に挙げます。

• 多くの帯域を提供する大規模ネットワークの構築方法を私たちは知らない。 Googleは同社のネットワークが二分割帯域幅で1Pb/sを提供すると言いますが、それでも十分でないことが判明しました。データセンターに値する大規模な計算サーバを支えるには、5Pb/sのネットワークが必要です。なお、現在のインターネット全体でも200Tb/sといったところでしょう。
• 巨大なクラスタ上でジョブをスケジュールした方が効率的。 そうしないとCPUやメモリがあちらこちらに取り残されることになってしまいます。システムを正しく構築できれば、データセンター規模のコンピュータは大規模化によるに効率向上をはっきりともたらしてくれます。
• Googleはサーバやストレージの世界を通じて得た教訓を基にデータセンターネットワークシステムを構築した。 その教訓とは、スケールアウトし、論理的に集中管理をして、市販されているコンポーネントを使い、いかなる場合でも単体で使用しないということです。サーバやストレージ、ネットワークは統一体として管理します。
• I/Oのギャップが大きい。 Aminはそれを解決すべきと言います。解決されないなら、革新は止まるでしょう。ストレージ容量は分散化により増加しているため、ローカルストレージにアクセスするかのようにグローバルデータセンターのストレージにアクセスできるようになるでしょう。これはフラッシュや不揮発性メモリだと、難しくなる一方です。新たなフラッシュや不揮発性メモリが、プログラミングモデルを完全に変えることになると思います。注意：この話題を彼が展開しなかったのは、私としては非常に残念です。ぜひ、これについて彼と語り合いたいですね。

いい物語には、コア・アイデンティティをベースに行動する人物が登場するものです。Googleは、スケーラブルなソフトウェア・システムを構築する中で独自に育んできたユニークなビジョンによって活動しています。自らのビジョンに誠実でありつつ、従来の常識とは完全に異なるデータセンターネットワークを構築する勇気を持つのは、恐らくGoogleだけではないでしょうか。それに取りかかるにはとてつもない覚悟が必要となります。いい物語とは、そんな時に生まれるのです。

次に、悲しくなるほど不十分ですが、私なりに講演を解説します。

• 10年以上にわたり、数多くの人々が取り組みに貢献してきた。
• 30年ほど前、BSDにソケットが導入されると、分散プログラミングも同じような課題に直面した。それが今、変わろうとしている。
• ムーアの法則の終焉により、コンピュータの使用に対する私たちの考え方を変えなければならず、分散コンピューティングの意味するところも今後、変わってくる。
• コンピュータの使用について、あるいはシステムをどのように構築したいかの鍵を握る部分は、ストレージ周りとなる。
• ムーアの法則にほぼ従う形で、ストレージや処理能力は大幅に増加してきた。
• I/Oのギャップは残っている。プロセッサとそれが処理する内在データ間の距離は増え続けている。
• 建物全体に分散されているディスクは、どのサーバからも利用できる。これは素晴らしい。同時に、今の処理能力があれば、それよりずっと広い範囲も視野に入れられる。
• 分散コンピューティング環境における大規模な次世代フラッシュの開発は、ほとんどが手つかずのまま。
• ネットワーキングは、コンピュータ使用の将来において重要な役割を果たすことになる。
• ネットワーキングは現在、転換点を迎えている。コンピュータ使用の意味合いは、優れたネットワークを構築する能力によって決まることになる。
• そこでデータセンターネットワークは重要な差別化の要因となる。
• Googleは建造物規模のコンピュータを構築する。立ち並ぶコンピュータと立ち並ぶストレージ。

• 長年にわたり、Googleは同社のハードウェアインフラを活用するためにソフトウェアを開発してきた。

  • GFS（2002）、MapReduce（(2004）、BigTable（2006）、Borg（2006）、Pregel（2008）、Colossus（2010）、FlumeJava（2012）、Dremel、Spanner。
  • これらの積み重ねが今日の分散コンピューティングを特徴付けている。
• 世界クラスのネットワークインフラがない限り、世界クラスの分散コンピューティングインフラは構築できない。世界クラスのネットワークでまとめることなしに、10万台のディスクを活用するGFSのようなシステムをどうやって構築できようか。

• ネットワークにおけるGoogleの技術革新：

  • Google Global Cache（2006）：世界中の地点から動画や静的コンテンツなどのコンテンツを配信するための方法。
  • Watchtower（2008）
  • Freedome：キャンパスレベルの相互接続。
  • Onix（2010）
  • BwE（2010）
  • B4：GoogleのソフトウェアWAN。世界中にある同社のデータセンターをまとめて接続する。一般向けのネットワークよりも大きく、拡張の度合いも速い。
  • Jupiter（2012）：高帯域幅のデータセンター規模のネットワーク。
  • Andromeda（2014）：ネットワークの仮想化。基盤となるネットワークインフラをどのように取り扱い、どうやって個別の仮想マシンに切り分けて、それぞれが独自に利用可能な高性能ネットワークを持つかのように見せるか。Googleが同社サービス（負荷分散やDDoS攻撃からの保護、アクセス制御リスト、VPN、ルーティングなど）に使ってきたのと同種のネットワーク仮想化をどのように立ち上げ、RAWハードウェア上で動作する分離されたネットワークで利用できるようするか。
  • QUIC
  • gRPC：Google、負荷分散、アプリケーションレベルのフロー制御、呼び出しのキャンセル要求、直列化、オープンソース、HTTP/2といったものの内部で使われるマルチプラットフォームのRPC。分散型サービスを構築するための素晴らしい土台。

データセンターのネットワーキング

• データセンターのネットワーキングは、従来のインターネットネットワークとは異なる。

  • 単一の組織によって運用され、事前に設計される。インターネットは、それがどのような姿なのか、探らなければ分からない。データセンターの中ではネットワークの姿は実際に分かっている。自分が設計して、自分が構築したからだ。したがって、手探りで進みながら理解しなくても、集中的に管理することができる。データセンターは単一の組織の管理下にあるので、独特のソフトウェアを実行させてもかまわない。20年来の遺産との互換性は必要ないので、自分に必要なことをさせるように最適化することができる。
  • 人々をネットワーキングに惹きつけるものは、問題の魅力。魅力とは、それが難題だということ。問題をもっと単純に、もっと拡張性を高く、もっと簡単に定義できるだろうか?
• Googleには、新しいネットワークが必要だった。Googleは10年ほど前に、伝統的なネットワークアーキテクチャでは、そのハードウェアとソフトウェアのどちらもが、帯域幅の需要と、データセンター内に分散されたコンピューティングインフラの規模に 対応し続けることができない ことに気づいた。

• 購入は可能か?

  • Googleの分散システムの要件を満たすデータセンターネットワークは、どんなにお金を積んでも買えなかった。

• 運用は可能か?

  • 個別ネットワーク主体のデプロイメントには、 複雑な運用 の費用がかかる。Googleが可能な限り大きなデータセンターネットワークを買ったとしても、個々のネットワークを運用するためのモデルはそれぞれのネットワークごとに異なり、コマンドラインインターフェースも別々になっている。
  • すでにGoogleは、数万台のサーバを1台のコンピュータであるかのように扱い、数10万台のディスクを1台のストレージシステムであるかのように扱う方法を知っていた。1000台のスイッチを1000台のスイッチとして管理しなければならないという考えは、 ほとんど意味がないし、不必要に難しいと思われた。

• 自前で構築

  • サーバとストレージの世界で学んだことからの着想： スケールアウト
  • もっと大きなネットワークやもっと大きなルータを購入する方法を考えるよりも、サーバとストレージでやったように、 市販の構成要素を追加 して回線交換と経路設定のインフラの規模を拡張できる。
  • 必要になったら 別のネットワーク要素をプラグイン してポートと帯域幅を増やせばいい。

• Googleのデータセンターネットワークの拡張を可能にした３つの主要原理：

  • Closトポロジー。 市販の小型スイッチを活用して、拡張も縮小も無限にできる、閉塞のない非常に大きなスイッチを構築するという考え。
  • 市販の半導体チップ。 Googleは広域インターネットインフラを構築しようとしているわけではなかったので、巨大な経路設定テーブルや大掛かりなバッファリングは必要なかった。つまり、データセンター内にClosベースのトポロジーを構築することは、市販の半導体チップで可能になる。
  • 集中管理。 ソフトウェアエージェントは、ネットワークがどんな姿であるべきか、どのように経路設定すべきか、また、基礎設計からの例外にどのように対応すべきか知っている。ネットワークの形を知っていれば、ネットワークの姿を知るために手探りし続ける場合に比べて、ネットワークの管理はずっと簡単になる。ネットワークを変更したいときは、集中管理ソフトウェアに命じてネットワークを変更させればいい。
• データセンターへの手法をキャンパスネットワークにも適用して、建物をまとめて接続し、広域ネットワークに接続した。B4とAndromedaは、長年にわたって自前のハードウェアと集中管理インフラの構築を実践してきたデータセンターでの仕事から着想と情報を得ている。

• データデンターの帯域幅は6年間で50倍に成長

  • Googleのサーバに供給することが必要な帯域幅の量は、ムーアの法則を超える勢いで増加する。
  • これは、帯域幅の需要増に追従するためには、Googleには規模の拡張が必要であることを意味する。古い機器を取り払って新しいネットワーキングを導入することは不可能ではない。

• 規模がアーキテクチャの決定要因

  • 現在の典型的なネットワーク（Googleに限らず）には、1万台を超えるスイッチと、25万本を超えるリンクと、100万個を超える経路設定ルールがあるだろう。 このような大規模なネットワークを取り扱う方法は、小規模なネットワークとは根本的に異なる。

• 全データセンター規模でネットワークを構築する理由

  • 最大級のデータセンターには、数100メガワットのコンピュータインフラを有するものもある。
  • 規模を拡大してスケジュールしなければ、大量にリソースが座礁する。ある共有インフラで実行することが必要な異なるジョブが多数あり、ジョブは1つのクラスタの境界内でスケジュールしなければならないとする。例えば、1000台のサーバクラスタが10個の場合と、10000台のサーバクラスタが1個の場合を比べると、任意に選べるなら、10000台のサーバクラスタでスケジュールを組む方が、はるかに高い効率が得られる。10000台のサーバのどこにでもジョブを割り当ててよいのなら、1000台のサーバに収めなければならない場合に比べて、結果はきわめて明白だ。このように、ネットワークを建物全体に拡張できれば、計算処理から、またディスクからも、もっと高い効率が引き出される。そして、大きな費用のかかる部分が整理される。ネットワークはとても低額になり、計算処理とストレージの効率がとても高くなる。
  • “リソースの座礁”とは、あちらこちらに取り残されたCPUやメモリがある状態（ 参考記事 ）。

• データセンターのバランスをとること。

  • 建物の規模にまで拡張したら、十分な帯域幅を確保しなければならない。
  • バランスのとれていないデータセンターでは、 不足しているリソースが価値を制限する。 あるリソースが不足すると、他のリソースがアイドル状態になることがあり、費用が増加する。
  • 通常、データセンターの規模では、最も不足するリソースはネットワークだ。ネットワークはプロビジョニング不足になりやすく、その理由は、私たちが多くの帯域幅を提供する大規模ネットワークを構築する方法を知らないからだ。

• 帯域について。アムダールの別の法則。

  • 並列計算において計算を実行する場合、1Mhz毎に1Mbit/sのI/Oが必要となる。
  • 事例として検討するためだけではあるが、次のような将来のデータセンターを想定してみる。サーバ群全体で64×2.5Ghzのコアを有する場合、各サーバがバランス良く動作するためには、大体100Gb/sの帯域が必要となる。ここで問題になるのはローカルのI/Oではない。ローカルのI/Oとは関係なく、データセンター全体でのI/Oを検討する必要がある。データセンターには5万台のサーバがあり、フラッシュストレージでは10万回以上のIOPSを、100マイクロ秒のアクセスタイムで、ペタバイト単位で処理しているかもしれない。技術が発展するにつれて、中には100万回以上のIOPSを10マイクロ秒のアクセスタイムで、テラバイト単位で処理出来るような不揮発性メモリ(NVM)も出てくる可能性がある。
  • すなわち、5Pb/sのネットワークと、それに対応可能なスイッチを用意する必要がある。たとえオーバーサブスクリプションが10:1であったとしても、平衡をほぼ達成するためには、500Tb(テラビット)/sのデータセンターネットワークが要求されていることになる。この容量は、現時点における全世界のインターネット総量（おそらく大体200Tb/s）を超えている。

• 遅延について。ストレージインフラの分散化を達成するためには、予測可能な範囲に遅延を抑える必要あり。

  • ディスクは10ミリ秒のアクセス遅延分遅いだけなので、ローカルに見せかけることは簡単。ネットワークだと更に速い。
  • フラッシュメモリとNVMではより難しい。

• 可用性について。拡張計画を十分に許容できる建造物が必要。新サーバは継続的に導入され、サーバは1ギガ→10ギガ→40ギガ→100ギガ→それ以上へとアップグレードされる必要がある。

  • アップグレードの度に建物を変えることは出来ない。投資が大きくなりすぎる。一方で、ネットワークとサーバの更新は定期的に行われなければならない。性能にほとんど影響を与えることなく、今まで使っていた建物で、新しいシステムを活かさなければならない。
  • ネットワーキングのスケールアップは機能しない。データセンター全体に張り巡らされているネットワークにおいて、焦土作戦的にアップグレードを実施することは不可能である。
• Googleのクラウドプラットフォームは、データセンターネットワークというインフラ上に構築されている。このインフラが、Googleの規模、パフォーマンス、可用性をサポートしている。そして一般に開放されている。次に出てくる偉大なサービスが、新たなインフラの開発を必要とすることなく、今あるこのインフラを活用できるよう願っている。
• 挑戦の鍵は、ハードウェアの物理容量を開放している間でも、分離性を保つこと。

ソフトウェアベースのネットワーキング（Software Defined Networking: SDN）

• ネットワーキングとは、次世代型コンピュータアーキテクチャの実現を可能とする、もしくは差異化を決定する重要な要素。SDNが大きな役割を果たす。
• SDNとは、複雑性を要約し処理をする コントロールプレーン をソフトウェアが担っているネットワークのこと。これまでの手法とは異なり、ネットワークに対するインターフェースが変わることになる。標準化された既存のプロトコルは使わない。代わりに、複雑性を管理して閉じ込めることが出来る、かつ1万個以上のスイッチをまるで1つのように扱うことが出来るようなソフトウェアコントロールプレーンを採用する。
• ハードウェアの存在。各機器をどのようにして、まるで1つの大きな集合体として管理するかが問題である。サーバ、ストレージ、ネットワーキング、それぞれの側面から検討する必要がある。
• 他社同様にGoogleも、最初は4ポストで構成されたクラスタネットワークを採用してデータセンターネットワークを構築。ネットワークサイズと帯域は、購入できる最も大きなルータによって決定された。より大きな容量が必要になる場合には、より大きなルータで別のデータセンターを構築しなければならなかった。
• Closトポロジーに関するアプローチとしては、市販の小型スイッチとシリコンを使って、次の図のような5世代にわたるネットワークを構築。

• 階層化したClosベースのトポロジーでは、建物の規模に見合った広帯域を実現するために、市販の半導体チップを応用。このシリコンを使ってラック上部のToRスイッチが作られている。ToRスイッチはサーバ群をまとめて繋ぎ、Aggregationブロックに働きかける。すなわちこのブロックが、一定の数のラック間における接続を提供している。同じく、このシリコンが、Edge Aggregationレイヤーをまとめ、Spineレイヤーへと働きかける。
• 10年前の段階では、集約された帯域は2Tb/s。最新世代におけるJupiterファブリックでは1.3Pb/sの帯域に。これらJupiterのSuperblockスイッチは、80Tb/sの帯域を運用できる。OpenFlowを使ってSDNソフトウェアスタックをホストしており、遠隔で操作出来る。このスイッチは、Googleが望んでいた通りにバランス良く、データセンター全体に働きかける。

ネットワークコントロール

• Googleは初期の頃、コントロールプレーンをどのように構築するかという選択に直面。既にサービスプロバイダに利用されているOSPF、ISIS、BGPといったスタックを採用するか、自前で構築するか。

• 独自で構築する方針を採用。理由は次の通り。

  • 10年前にGoogleが検討していたトポロジーでは、マルチパスの転送機能が必要だった。理想的な帯域を実現するためには、送信元と宛先の間で、非常に多くの経路が必要とされていた。しかし既存のプロトコルはマルチパスをサポートしていなかった。接続性に関連する問題であり、送信元から宛先までの経路は探索したが、それは最良の経路ではなく、マルチパスでもなかった。
  • 10年前には高品質のオープンソーススタックが存在していなかった。
  • 全てのプロトコルはブロードキャストベースであった。Googleが運用しようとしている規模のネットワークでは、ブロードキャストベースのプロトコルだと拡張性が危ぶまれた。
  • 一旦ブロードキャストベースのプロトコルが導入されてしまうと、使われている個々のボックスそれぞれに、そのプロトコルを設定する必要が出てくる。それはGoogleが好まないところである。

• まとめると、Googleによる規模の大きな巨大システムの構築を通じて、新たに以下のような定型的な見識が得られた。

  • 階層的なコントロールプレーンと、P2Pのデータプレーンを使うことで、 論理的な集中化を実現し （1台のサーバだけ使うという意味ではない）、完全な分散モデルを妨げる。これまでに何度も何度も繰り返し実行されており、データセンターネットワークでも同様である。
  • スケールアップよりも スケールアウト の方がずっと簡便である。この事実はGFSやMapReduce、BigTableやAndromedaの観点からも明確である。
  • 設定と管理の集中化 により、システム全てにおける振る舞いと展開を劇的に単純化できる。

関連記事

• On HackerNews / Jupiter Rising on HackerNews
• Google’s experience with Software Defined Network Function Virtualization at Scale (Google video, 2014)
• A visual look at Google’s innovation in Global Network Infrastructure
• Pulling Back the Curtain on Google’s Network Infrastructure
• A look inside Google’s Data Center Networks (Google blog post, on HackerNews , on Reddit )
• Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network (Google paper, 2015)
• SDN Stack for Service Provider Networks (Google video, 2012).
• Show 222 – Introducing The OpenClos Project (networking nitty gritty from Packet Pushers)
• Google Throws Open Doors to Its Top-Secret Data Center (Wired, 2012)
• Changing Architectures: New Datacenter Networks Will Set Your Code And Data Free (from HighScalability)
• VL2: A Scalable and Flexible Data Center Network (paper from Microsoft)
• Google On Latency Tolerant Systems: Making A Predictable Whole Out Of Unpredictable Parts (from HighScalability)
• Introducing data center fabric, the next-generation Facebook data center network
• The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems (looks like a good book)
• Inside A Decade Of Google Homegrown Datacenter Networks
• Tech Takeaway 012: Cluster Management at Google
• Evaluating job packing in warehouse-scale computing
• Exascale Computing—a fact or a fiction?
• RECONCILING HIGH EFFICIENCY WITH LOW LATENCY IN THE DATACENTER
• ONS 2015: Wednesday Keynote – Mark Russinovich – Microsoft’s take on networking.